CP-4498: Added relaxed check mode to allow iSCSI SRs during XSM #1116
Conversation
|
Can one of the admins verify this patch? |
|
Ok to test On Monday, March 25, 2013, xen-git wrote:
Dave Scott |
| try | ||
| let dest_vdi_ref = XenAPI.VDI.get_by_uuid remote_rpc session_id vdi_uuid in | ||
| let dest_vdi_sr_ref = XenAPI.VDI.get_SR remote_rpc session_id dest_vdi_ref in | ||
| if dest_vdi_sr_ref = dest_sr_ref then |
There was a problem hiding this comment.
Do you want to be testing to see whether the SR references are the same or the uuids? I would have thought uuid would be better in that I can see a way to ensuring this is the same between pools, whereas I can't see how the references would ever be the same.
There was a problem hiding this comment.
It's checking that the VDI requested exists on the SR that we've told XSM we want to migrate to.
dest_sr_ref is provided to the migrate_send function and must be the remote ref (personally I think this really should have been the UUID to remove uncertainties) - dest_vdi_sr_ref is therefore the SR which the VDI already exists on, and the check is that the target VDI is on the correct SR on the remote end.
There was a problem hiding this comment.
Note that the sr uuid is also checked at line 292
ghost
assigned
|
Can one of the admins verify this patch? |
|
ok to test |
|
Can we put in a strong warning or even error if we believe that the SR uuids match but the VDI doesn't exist on the other side? That's a situation we ought to be really worried about :-) |
|
If the VDI doesn't exist we could do an SR.scan, since xapi's view might On Tuesday, April 2, 2013, Jon Ludlam wrote:
Dave Scott |
|
Added an error and an SR scan. Because these are both exceptional cases I'm not sure how to test them - so I'm hoping a visual inspection will suffice. |
Signed-off-by: Bob Ball bob.ball@citrix.com
|
OK, looks good now! |
|
So what needs to happen next for it to be merged? |
|
Me to click the button :-) we had a minor freeze last week for a Linux 3.x change to go in, but we've thawed now. I'll merge now. |
CP-4498: Added relaxed check mode to allow iSCSI SRs during XSM
|
Thanks Jon! |
Fix for bug 1160323. DocImpact Depends on a version of XAPI supporting relax-xsm-sr-check. Currently no release versions support this, so the change at xapi-project/xen-api#1116 would need to be applied to the source to enable this. XenServer 6.2 is expected to support this mode, and possibly some future hotfixes for XenServer 6.1. It also depends on a configuration change which must be documented and added to devstack: * Set "relax-xsm-sr-check = true" in /etc/xapi.conf This commit makes the following changes: * Attach the SR on the destination host prior to migrate * Returns the SR-ref from the pre_migrate call (API change) * Populates the XS VDI map with the sr-ref on the destination host * Removes the connection to the SR from the source host post-migrate * Added plugin to determine if iSCSI block migration is enabled Associated tempest test at https://review.openstack.org/#/c/26478/ Change-Id: I917d9cf094190d636f4b9e14f6c8e728ff85af0e Fixes: bug 1160323
Fix for bug 1160323. DocImpact Depends on a version of XAPI supporting relax-xsm-sr-check. Currently no release versions support this, so the change at xapi-project/xen-api#1116 would need to be applied to the source to enable this. XenServer 6.2 is expected to support this mode, and possibly some future hotfixes for XenServer 6.1. It also depends on a configuration change which must be documented and added to devstack: * Set "relax-xsm-sr-check = true" in /etc/xapi.conf This commit makes the following changes: * Attach the SR on the destination host prior to migrate * Returns the SR-ref from the pre_migrate call (API change) * Populates the XS VDI map with the sr-ref on the destination host * Removes the connection to the SR from the source host post-migrate * Added plugin to determine if iSCSI block migration is enabled Associated tempest test at https://review.openstack.org/#/c/26478/ Change-Id: I917d9cf094190d636f4b9e14f6c8e728ff85af0e Fixes: bug 1160323
Signed-off-by: Bob Ball bob.ball@citrix.com